
-------- TML Message #1771 --------

Archive-Message-Number: 1771
Date: Wed, 14 Nov 90 13:44:25 GMT
From: grue@batserver.cs.uq.oz.au
Subject: all sorts of things....

hiya,

>Date: Sun, 11 Nov 90 21:39:24 -0900
>From: George William Herbert <gwh@ocf.berkeley.edu>
>Subject: (1749) Fixing Maneuver Drives...
>
>W. Dow Reider says:

>Re: newtonian violations...
>	There's a neat explanation for how to get reactionless drives...
>some work by one Robert L. Forward into negative matter shows that with
>some negative-mass nearby you can move by interaction with the negative mass
>but not using exhaust.  If you want to extrapolate those results into playing
>with gravity i just bet that you can get away with reactionless drives.

>	Robert Dean thought that a straight thrust-based system would work 
>better... I agree, but pose a question: is it worth introducing incompatability
>if we have means to remain compatable ?

How about the following idea (would one of the physics types verify if this
is possible):
	You generate a LOT of energy,
	convert the energy into mass (E=MC^2, thus matter and energy
				are really the same) and
	then throw the mass out the back.

	You'd have a reaction-based drive that didn't consume matter
	(except that the energy generation would use up heaps of matter).

Would it be better to use your power plant fuel as propellent?


Now onto a more serious issue (sorry if this sounds a bit flamish, it isn't
really ment to be):

>Date: Mon, 12 Nov 90 13:40:13 EST
>From: Robert P Poole <tarquin@athena.mit.edu>
>Subject: (1756) TDR, TeX, character generation

>I don't recall who voted "no" on TeX, but I have to say this guy doesn't know
>what he's talking about.  TeX is not cumbersome.  Sending proprietary files
>formatted for one word processor or another and trying to convert them is
>cumbersome.  With TeX, you send the source file as plain text, and the other
>person can make instant use of it.  I assume that the people on this list are
>intelligent enough to see the advantage of using the net to write this thing
>up.

I would vote very strongly NO for TeX.
My vote would be for plain text (maybe include a postscript version that looks
nicer).

My major objection to TeX is that I'd have to learn something which I have
no desire to know anything about.  Even with the macros suggested,
I'd still have to learn something new.  I'd also have to know how to access
TeX on whatever system I was using (if it even HAD TeX, not everybody has).

What happens if I would like to boldface titles?  Creation of tables (rather
than formatted text)?  Subscripts?  Superscrips?

The point is I would have to learn how to do these things.  I have no desire
to learn a user-alien text formating system.  I also realise that the nice
word processors that I do own are not going to be any good to most of the
people since they use their own internal formats.

Everybody can use text (ASCII) files, everybody should be able to read them
and print them.  So what if they don't come out quite so nicely?  If we
seriously want to PUBLISH the results of the re-design then we can format
the manuscript after it has been written.  If it is as easy as was made out,
this reformat should pose no problems whatsoever.


>Look, let's be fair and realistic.  Fair in that everyone who wants to should
>be able to work on part of the project and have input.  Realistic in that if we
>only let a few select people do the actual work, it will never get done.

Letting everybody be able to provide input is exactly the reason that we should
use a format that everybody has.  I say again that not everybody has access
to TeX.

[
 I should note here, that I personally don't own TeX in any form.  I do have
 access to TeX and would be willing to learn enough about it if TDR was going
 to be distributed in that format.  However, I do not desire to learn it.
]


>About automating the generation rules:  Good.  I am glad someone suggested
>this.  We should make executables available to PC and Mac users for character
>generation, star system generation, starship design, and world map generation.
>We should also make the sourcecode available for people to port to other
>systems.

I think that I was the one who suggested it (which I didn't really do).  I
do think that this is a really good idea.  There may be difficulties modifying
existing programs to work with any new stuff we create.  The ship design
program (coming soon, it is being beta tested ---- sort of) should be able
to take most modifications without too many problems.  I haven't looked into
the other programs available to see how hard they are to modify.  Hopefully,
the changes will not be too sever and they can be modified.  Rewriting from
scratch will be a major headache.  Even modifications can be unpleasent.
(Does anybody realise the quantity of data present in the MT books?  As an
example the ship design program uses a data table that is quite big wc gives
the following figures (the table is human readable text with comments included):

    2138   21011  117516 dat.tbl

I realise that this table contains a lot of redundant stuff because I tried
to capture the special cases in the data table and not in the program (which
is why I believe it will be easy enough to modify).

This task we are undertaking is looking to be a VERY large one.



							Pauli
seeya

Paul Dale               | Internet/CSnet:            grue@batserver.cs.uq.oz.au
Dept of Computer Science| Bitnet:       grue%batserver.cs.uq.oz.au@uunet.uu.net
Uni of Qld              | JANET:           grue%batserver.cs.uq.oz.au@uk.ac.ukc
Australia, 4072         | EAN:                          grue@batserver.cs.uq.oz
                        | UUCP:           uunet!munnari!batserver.cs.uq.oz!grue
f4e6g4Qh4++             | JUNET:                     grue@batserver.cs.uq.oz.au

-------- TML Message #1772 --------

Archive-Message-Number: 1772
Subject: Internal consistency and weapon skills
Date: Wed, 14 Nov 90 17:27:19 X
From: Iain Fogg <iain@batserver.cs.uq.oz.au>


There's been considerable discussion in the TML recently regarding
weapon skill categories. Allow me to put in my two cents worth.

Consistency! When I look at a game system I look for consistency.
Essentially, I'm after an equivalent level of abstraction in all aspects
of the game. Individuals who argue for weapon skills in individual
weapons clearly do not. For example, if you believe that there should be
different skills for handling an automatic snub pistol and a gauss
pistol, would you also expect to see separate skills for repairing a
ship's maneuver drive and am automobile? Except for weapon skills,
most people are prepared to accept a high level of abstraction,
because otherwise the number of skills, by necessity, explodes.
Why does this differ for weapons? Beats the hell out of me.

As a real world example, I served for three years in the Australian
Army Reserve. At that time the standard issue infantry weapon was a
7.62mm SLR. We also learnt to handle the M-16. While the stripping and
cleaning of both these weapons differed quite markedly, they were not
that different when they were fired (the SLR had a bigger recoil).
Therefore, I argue that the justification for introducing individual
weapon skills because they are made differently is totally inconsistent
with the rest of the MegaTraveller game system.

My basic message is that many people are looking to complicate a
simple activity. Fire one rifle, you've fired them all. Fire one handgun,
you've fired them all. Just as with the mechanical skill - fixed one
engine, you've fixed them all. Consistency!

Iain.

-------- TML Message #1773 --------

Archive-Message-Number: 1773
Date:     Wed, 14 Nov 90 0:49:47 PST
From: Orcinus orca <jokim@jarthur.claremont.edu>
Subject:  All sorts of things

Black Globes:
Someone said the energy absorbed can't be used in the new rules.
Ignoring that, it should still be advantageous to fire all your
weapons while inside the BG.  Since most of your weapons aren't
operating at 100% efficiency, a lot of that energy is going to
be converted to heat, most of which will heat up the ship and
thus not place a strain on the capacitors from reabsorbed energy.

That is, assuming the energy to fire the weapons came from the
capacitors.

P.S.  If you don't like the physics violations in Traveller,
don't even think about White Globes.  It's basically a Black
Globe which absorbs all incoming energy, yet somehow the
person/ship inside can see out.

Reactionless Drives:
The greatest benefit of reactionless drives is that you dont'
have to solve a differential equation to figure out the speed,
range, and acceleration of your ship when you have x tons of
fuel left.  Is there a way to achive this simplicity with
Fusion Drives?  And keep in mind a ship loses a good deal of
mass during a jump.

Gravity Field Warps:
Is this truly mass-independent?  If you can generate a gravity
field with x amount of energy, and it doesn't matter how big
the mass influenced by the field is, with a sufficiently large
mass, you can gain more kinetic energy than x-- another perpetual
motion machine.

btw, I like the idea of a gravity field warp (it's the unofficial
explaination for the Star Trek "warp drive").  It always reminds
me of the cartoons where someone is holding the top of a door or
birdbath and pushing the bottom with his/her/its feet, and the
door/birdbath keeps moving forward.

TDR:
You need not start a company immediately to publish it.  Just
make sure the stuff you send to GDW is in parts (pretty simple
considering the amount of overhaul proposed).  Then have GDW
sign some legal form saying the authors have full rights to
any future publication.  Then if people love TDR in the GDW
publications, you can work out future details through snail
mail and have full rights to a *complete* version of TDR.

I agree with ASCII.  Anybody can read it and print it out on
the fanciest printing resources he has access to.  And if you
guys do eventually publish, most printing shops have to convert
it by hand onto their own machines anyway.  I think the stuff
that prints Tex at 1200+ dpi costs about $4/page.  Dunno about
bulk rates.

Is there going to be TDR mailing list?  Will it go the way
of past mailing lists whose problems were, as someone told me,
"All they ever did was talk about considering discussing the
planning to lay the foundation of starting to begin to get
something done."
- - --
John H. Kim
jokim@jarthur.claremont.edu
uunet!jarthur!jokim

-------- TML Message #1774 --------

Archive-Message-Number: 1774
From: Adrian Hurt <adrian@cs.heriot-watt.ac.uk>
Subject: Re: Black Globes
Date: Wed, 14 Nov 90 9:45:44 GMT

Paul Baughman writes:
> (Paul doesn't mention it, but I, Adrian Hurt, wrote):
> >I'd refer to the MT white globe as "the ultimate defense".  Getting one is
> >a neat trick, though! ;-)
> 
> Huh?  wazzat?

I'm sure I read about this in a MT manual, which isn't here right now for me
to check.  Instead of absorbing energy, it reflects it.  It isn't much use as
a cloaking device, of course.  I can't remember whether or not it allows you
to fire out through it.  I think it is available at some ridiculous tech level
(TL 20+, maybe).

Actually, firing out of a black globe shouldn't be a serious problem.  You
synchronise your fire with the flickering.  It might be necessary to have a
slightly longer than usual period that the globe is off, to allow some fire
(especially missiles) to get through.  At the simplest, have an interrupter
circuit fitted into the generator which turns the globe off, permits weapons
to fire, then turns the globe back on.  The drawback, of course, is that the
enemy might hit you while you're firing.  This could be accidental (roll
dice to see if the enemy got lucky when he fired) or intentional (the enemy
needs to make some sort of Sensors task roll).

> (Someone else not credited wrote):
> >Globe is turned on the ship can't fire, communicate or maneuver. The Ship
> 
> Why can't it maneuver?  With reactionless thrusters which don't emit anything
> to be absorbed by the field, you should be able to maneuver all you want.

And there's your answer.  This rule, like so much else, is lifted from good
old High Guard.  And in those days, no-one had heard of reactionless thrusters.

Yet again, I say: ignore the garbage about reactionless thrusters.  They're
silly, they violate the law of conservation of energy, and they add nothing
to the game except inconsistencies like the above.

- - -- 
 "Keyboard?  How quaint!" - M. Scott

 Adrian Hurt			     |	JANET:  adrian@uk.ac.hw.cs
 UUCP: ..!ukc!cs.hw.ac.uk!adrian     |  ARPA:   adrian@cs.hw.ac.uk

-------- TML Message #1775 --------

Archive-Message-Number: 1775
From: d9bertil@dtek.chalmers.se
Subject: COACC Engines vs Grav-modules
Date: Wed, 14 Nov 90 13:12:07 MET

  Here's what I got from a few minutes with a spreadsheet:

  Data is for enough Grav modules to reach the stated thrust and enough 
powerplant to provide them with energy.

Grav modules the best at TL
Thrust:	20tons		50tons		195tons	
TL	tons	KCr	tons	KCr	tons	KCr
9	40,8	2040,0	42,0	2100,0	47,8	2390,0
10	8,6	900,0	9,5	1650,0	13,9	5275,0
11	4,6	700,0	5,5	1450,0	13,7	5265,0
12	2,0	6080,0	5,0	15200,0	7,8	58695,0
13	1,2	6053,3	3,0	15133,3	6,8	58694,0
14	1,2	6053,3	3,0	15133,3	6,8	58694,0
15	0,7	6026,7	1,7	15066,7	5,2	58630,0

Grav modules the best except for the 300kCr per kl ones:)
Thrust:	20tons		50tons		195tons	
TL	tons	KCr	tons	KCr	tons	KCr
9	40,8	2040,0	42,0	2100,0	47,8	2390,0
10	8,6	900,0	9,5	1650,0	13,9	5275,0
11	4,6	700,0	5,5	1450,0	13,7	5265,0
12	3,8	660,0	5,5	1450,0	13,7	5265,0
13	2,2	606,7	5,5	1516,7	9,8	5135,0
14	2,2	606,7	5,5	1516,7	9,8	5135,0
15	1,1	553,3	2,8	1383,3	7,8	5069,0

Just standard grav modules.
Thrust:	20tons		50tons		195tons	
TL	tons	KCr	tons	KCr	tons	KCr
9	40,8	2040,0	42,0	2100,0	47,8	2390,0
10	8,8	440,0	12,0	600,0	33,8	1690,0
11	4,8	240,0	12,0	600,0	33,8	1690,0
12	4,8	240,0	12,0	600,0	33,8	1690,0
13	3,8	239,0	7,0	433,3	27,3	1690,0
14	3,8	239,0	7,0	433,3	27,3	1690,0
15	2,1	173,3	3,7	266,7	14,3	1040,0

  This table is inacurate in two areas:
  1. The minimum powerplat volumes at lower TLs make it uneconomic to make
vehicles with as small thrust as less than 200 tons.

  2. I'm not 100% sure that I got the scale efficienct right.

  COACC engines, give 195t thrust for 4t of engine that costs 300kCr (Fusion 
Rocket) or 50t of thrust for 4t of engine (High bypass Turbofan) (add 10t if
an AB is used)

  The basic thing still stands: Many 'ordinary' engines give as good thrust
to weight ratio as Grav modules and is usually far cheaper. The drawback is 
very high fuel consumption, except for the fusion rocket.

(Sorry, have to rush, I've got a Electronics-3 class in 2 minutes:)

- - -bertil-
- - -- 
"Words on the net aren't usually worth the paper they are written on."

-------- TML Message #1776 --------

Archive-Message-Number: 1776
Date: Wed, 14 Nov 90 08:58:10 -0800
From: "Ted Kim (Random Dude" <tek@lanai.cs.ucla.edu>
Subject: bursting & digest format


Occasionally, when bursting the digest (even with James's new burst
program), I end up with resent messages that have inappropriate
headers. In particular, the "From:" field reads that it is from me.
For example, when bursting article 1770 in TML Nightly Volume 12,
Issue 9, I end up with such an erroneous "From:" line. 

I think this is because the corresponding digest article is missing
header fields and the mailer decided to put something in that field
(me). For example, article 1770 header is missing the "From:" line.

> Date: Tue, 13 Nov 90 16:05:08 -0500
> Reply-To: al646@cleveland.freenet.edu
> Subject: (1770) Reactionless Drives

I assume the digest article is missing a field, because no such field
existed in the original message. This is somewhat puzzling as I
believe RFC822 requires an authenticated originator "From:" field.

Regardless of why it's missing, can the TML software back at TML HQ be
modified to stick in a "From:" field if it's missing in a message?

[Actually, the messages do come in with a From line.  The TML digester
deletes it if there is a Reply-To! I see now this was a silly decision
on my part, and starting tonight, the From lines will always remain
unmolested -- James]

- - -ted

Ted Kim                           Internet: tek@penzance.cs.ucla.edu
UCLA Computer Science Department  UUCP:     ...!{uunet|ucbvax}!cs.ucla.edu!tek
3804C Boelter Hall                Phone:    (213)206-8696
Los Angeles, CA 90024             FAX:      (213)825-2273

-------- TML Message #1777 --------

Archive-Message-Number: 1777
Subject: TML Admin apologizes again
Date: Wed, 14 Nov 90 10:22:24 PST
From: James T Perkins <jamesp@metolius.WR>


I'd like to apologize again for the problems last night.  It was
programmer error.  Everything will be back to normal tonight.

I realize that not only were the barrage of tiny digests annoying, but
that the multiple copies of the same thing was confusing.  I also
realize that some of you pay to download these messages, and cannot read
them until they finally get into your computer.  I also realize that
some of you are forced into reading all this mail whether you want to or
not -- at 1200 baud.

If it's any consolation, I am receiving piles of mail bounces off of
inactive accounts, so I am not getting a moment's peace.  Guess I'm
getting appropriate punishment.  I'm also answering individual inquiries
of the form "wha' happen'?".

In the mean time, I will offer to resend any digests to anyone of you
who asks.

We now return you to your normal nightly and biweekly 50K-byte digest
digesting (unless I screw it up adding the code to sort starship designs
to the end of the digest).

James
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Traveller Mailing List Administrator	     James T Perkins @ Tektronix, Inc
traveller-request@metolius.wr.tek.com	     Beaverton, Oregon, USA
uunet!metolius.wr.tek.com!traveller-request  "Load Auto/Evade, Beowulf!"

-------- TML Message #1778 --------

Archive-Message-Number: 1778
Subject: TML Digests are now sorted
Date: Wed, 14 Nov 90 12:23:13 PST
From: James T Perkins <jamesp@metolius.WR>


TMLers:

Well, after much testing (I figured out how to test the digester
successfully, which should help avoid things like last night), the TML
digests are now sorted as I talked about in previous messages.  The
recipe is this:

	beginning of digest: messages smaller than 6K bytes
	middle of digest:    messages larger than 6K bytes
	end of digest:       vehicle designs, regardless of message size

Notice that long (non-vehicle design) messages are kept in the middle of
the digest -- this keeps all the snappy dialogue at the front.

A vehicle design is any message which contains 10 or more of the
following strings, ignoring case, with * a wildcard that matches any
number of arbitrary characters (in other words, this very message should
qualify as a vehicle design, as would one that listed craftid 10 times):

craftid:  Disp*=    power:    Loco*:    Sensor*:  Def*:     Crew=     
hull:     Config*=  Dur*=     Comm*:    Off*:     Control:  Accom*:   

TMLers, Let me know if this is a boon or a bust to you.

James
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Traveller Mailing List Administrator	     James T Perkins @ Tektronix, Inc
traveller-request@metolius.wr.tek.com	     Beaverton, Oregon, USA
uunet!metolius.wr.tek.com!traveller-request  "Load Auto/Evade, Beowulf!"

-------- TML Message #1779 --------

Archive-Message-Number: 1779
Date: Wed, 14 Nov 90 16:31:35 -0700
From: FELLOWS STEVEN B -5 CR <sfellows@slate.mines.colorado.edu>
Subject: Number 5: GET ON TRACK!

I have been reading this mailing list for over a year now, and after
subscribing to a few now defunct mailing lists and reading internet news
I can safely say that the idea of TDR is approaching that of oblivion.  

What!

I commit heresy?

Actually, let me just list in order of events what I have seen most of
these *ideas* go , and then my response on what we should do:

1)  There is a mailing list or group that has a common theme of gaming.

2)  After a certain amount of time of some realing good posts someone posts
the idea that we should all write a game.

3)  For about 3 days (I'm very serious about that number, not 2 or 4, but
3), people start posting ideas of what can be improved.

4)  On the fourth day someone suggests a name for the project.


******So far, so good.  ********

5)  Then the inevable group of posts start:

    a)   Copyright infringement laws.  This stream discourages people some.
    b)   Making money off of our work.  This stream discourages other
people even more.
    c)   Who is going to be in charge, and who does what.  This stream
really discourages people, because the very least they want is a deadline.
Remember, for most of us this is a hobby, albeit, an extremely entertaining
one (some believe ranks right up there with sex and food gluttonly).
    d)   "We should write computer programs that do all this."  Discourages
people who don't want to write computer programs, and don't care to drag a
computer to their session.
    e)   The formatting of the text.  Discourages people some , because we
are already receiving this mailing list, why does it have to be something
special again?  I mean, I am happy with getting this mailing list.  In the
same thread, I expect in 2 days, someone will say that a seperate offshoot
mailing list should be formed.  Irritates people, because now they have to
worry about more digests.
    

********DANGER*******

At this point, someone posts a letter, pleading with everybody else to get
on track.

{[

As one aside, I made a comment last Saturday during my groups Traveller
session (which started late, Sat at 1300, when it was suppose to start Fri
at 1800):   "All we seem to be able to decide in is our group indecision
and to put off making a decision for 2 hours."

This amused everybody then , and I think applies to the situation at this
point.  (By the way, our problem was what shall we do for lunch and
dinner?).

]}

AND, at this point , that poster is generally ignored.

6)  About 25% of the original people who liked the idea start on something.
50% continue arguing about the points in number 5.
25% go on to something else.

This all  happens about 1 week after the above problems start.

7)  After a while, everybody goes on to something else, except for the one
guy who originally posted the idea.


8)  AND, after a while, we are left with lots of posts concerning a
nonexistant game we were going to work on, and a lot of people wondering
what ever became of the project.



**********NOVEL  IDEA************

The original idea was proposed that we examine the MegaTraveller system,
and post our revisions of what each section should be.  Improve the system.

(At this point everybody is nodding their head and wondering why I am
wasting bandwith).

We are starting on number 5, folks, and pretty soon we will be at step
number 8.


Why don't we just post our revisions.  Now, we have some guidance and a
goal.  It is the same as before, except for a general theme.

The problem with number 5 issues, is that we are not a company.  This is
not our means of making a living.   At number 5, we are already discussing
something that should be discussed AFTER we have come up with some really
nifty ideas.

1)If you want to put it in Tex, LaTeX, Word, *ruff, *roff, or even SWAHILLI,
do it then.  It will come to you off this mailing list, and you can format
it for your own desire and tastes.  

Me:  I will take it into ASCII, dump it to a NexT machine, and then use the
Laser WRiter to print off a nifty looking copy.  And I will dump a copy to
the MAC for future use.

2)Computer programs.  Those who want them, go ahead and write them.  Noone
is stopping you.  Just don't tell me that I have to write a computer
program.

3)Copyright and making money.  Let me just say one thing....
So far on this list we have discussed the game, and played with changes.
We have not done anything illegal.  These posts are for our use, and whoever
we want to distribute them to for free.  Hell, if you charge money for a
letter I wrote I probably won't care.
  But, if any of us find out that someone has published our material
without asking us, then they will never , ever, get anything published
again.  All a publisher needs is a plagarist, to cause them headaches.
And, those of us who see our stuff in print, will cause those headaches:
end of matter.

4)Who is in charge, and who does what.  As for who is in charge, I don't
care.  We are just a group having fun.  Maybe there should be people who
keep us on track and remind us of things that need to be done.  These
people will appoint themselves.   

As for who does what, who cares .  If we see it needs to be done, and if it
needs to be done badly enough, it will get done .  (Whoa! Awful sentence!)
As for me, I said I would do some stuff with Trade and Commerce, because I
want it for my campaign.

If the material that someone writes is not very good, we will discuss it and 
try to improve it or rework it (or ignore it and drop it).  AS WE HAVE DONE
MANY TIMES IN THE PAST.

Folks, IF YOU WANT TO DISCUSS THE ISSUES OF NUMBER 5 IN THE FUTURE, PLEASE
JUST POST AS YOUR SUBJECT   "NUMBER 5:" AND THEN I WILL KNOW TO SKIP IT,
FOR IT WILL BE A WASTE OF TIME.

When we have a bunch of stuff collected together, maybe then we should
worry about what  do with it beyond our group.  

Thank you for your time in reading this, I will now proceed back to discussing
the game and any improvements or whatever....

Steven B. Fellows
sfellows@slate.mines.colorado.edu

-------- TML Message #1780 --------

Archive-Message-Number: 1780
Date: 14 Nov 90 18:42:00 EDT
From: "NUCENG::CRAIG" <craig%nuceng.decnet@pine.circa.ufl.edu>
Subject: Stuff for sale

For Sale/Trade :

Journal of Traveller's Aid Society :   3$/4$ each

7,9,15,17,18,21, Best of 1 and 3

Traveller Logbook (JG)                 $2

Astrogators Chartbook (JG)             $2

Ley Sector  (JG)                       $2

Ley Sector Guidebook (JG)              $2

Simba Safari (JG)                      $2

Starships & Spacecraft (JG)            $2

Traveller Referee Screen (JG)          $.50

Book 3 Worlds and Adventures           $2

Book 4 Mercenary                       $2

Book 5 High Guard                      $2

Book 8 Robots [new]                    $2

Supplement 2 Animal Encounters         $2

Supplement 4 Citzens of the Imperium   $2

Supplement 6 76 Patrons                $2

I am willing to listen to offers, and willing to trade in YOUR favor for 
items I am looking for.... i.e. DragonTales, The Finieous Treasury, old Dragon
Mags, Metaphosis Alpha.

You will be paying shipping. Unless you buy alot of stuff.

All Items are in very good to execellent condition. Ask AC@apple.com, We have
traded before.... He's knows the quality of items that I have.

Anyone know how much a IISS Ships Files would go for?

Craig@robot.nuceng.ufl.edu or zhou@beach.cis.ufl.edu

Warning: the first address has mailer problem at the worst times, please send 
2 message to both addresses if possible ... Thanxs...



-------- TML Message #1781 --------

Archive-Message-Number: 1781
Date: Thu, 15 Nov 90 8:54:38 GMT
From: Jo Jaquinta <jaymin@maths.tcd.ie>
Subject: Sysgen4 README

	Sysgen4 & suite will be available shortly on the archive server.
There have been some link problems getting it to a UNIX system to post
and it will be over as soon as those are sorted out. In the meantime some
commonly asked questions:

>What printers does it support?
	The whole thing is designed to be run on anything. Consequently
all of its output is dumb terminal ascii. There are one or two programs
that use Epson FX-80 escape sequences and are clearly marked. Two programs
only run under TurboC and use graphics. Other than that nothing fancy.
I would very much like to see other front ends written and will gladly help
interested people.

>I use a [insert wide variety of hardware]
	Perhaps I should have asked what operating system and compiler
people use. It has been throughly tested under MS-DOS with Lattice and
TurboC compilers. It will be tested on a SUN running SUNOS (BSD 4.3).
The 

- - ---------
	This file contains a brief description of each of the programs.
See _progname_.OUT for a sample output. All the times mentioned in the
outputs were done on a 20MHz 386.
	To compile copy one of the make files to makefile and type "make
all". You will probably have to modify it a little. There is only one 
compile time constant that is in magic.h. Define bit16 if your compiler
compiles ints to sixteen bits and comment it off otherwise.
	Please mail whatever changes you have to make to get it running
so I can update the information. In particular I would like proper UNIX
makefiles.
				Jo Jaquinta
				jaymin@maths.tcd.ie
				November 1990

SYSGEN1 xx yy zz
	This is the level one system generation program. It produces basic
mainworld information.

SYSGEN2 xx yy zz
	This is the level two system generation program. It produces extended
system information.

SYSGEN3 xx yy zz
	This is the level three system generation program. It produces 
information comparable with world builder's handbook.

SYSGEN4 xx yy zz PlanetName
	This is the level four system generation program. It produces 
surface maps for a planet. It prints a high level map on the screen then
asks which triangle to expand. The triangles are numbered as in (A)
	 /\  /\  /\  /\  /\             	 /\
	/ 1\/ 2\/ 3\/ 4\/ 5\    	        /1 \
	\ 6/\ 7/\ 8/\ 9/\10/\ 	               /____\
(A)	 \/11\/12\/13\/14\/15\   	(B)   /\ 0  /\
	  \16/\17/\18/\19/\20/  	     /2 \  /3 \
	   \/  \/  \/  \/  \/  		    /____\/____\
	Next is will ask for a specifier. Each of the 20 big triangles is
expanded as per (B). If no specifier is given you get the whole large
trianlge. If a specifier of 1, say, is given you get the top little triangle.
This is recursive. Thus a specifier of 131 gives the top triangle of the lower
right triangle of the top triangle of the world triangle. Get it? Well,
play around with it and see.
	Lastly it asks for size. This is basically the number of times to expand
while printing. This size 1 is as is, size 2 is two on a side, size 3 is 4 on
a side, ....
	You can expand down to 16 triangles per side. The program doesn't
limit you but you will see it starting to get really ugly. Again, 
experimentation is the best approach.

TTIMES xx yy zz
	This program computes the travel times between planets of the
star at the given system. It only computes them for the top layer though.

DETPRINT xx yy zz PlanetName
	This prints out level 3 details on a planet in English. Included are
physical stats, principal cities, local customs, local religion, law levels,
tech levels and hex row seasonal temperatures.

ORIGIN xx yy zz NumberPeople
	This is for finding origins of NPCs. You give it a system and the
number of origin planets to find. It first calculates the total population
from the vacininy then randomly selects planets based on population. It uses
the level 2 figures for the entire system to determine population.

SCANNER xx yy zz
	This is a simple interactive region examining program. It uses the
ANSI clear screen command. While in it the keys X, x, Y, y, Z, z shift along
the given axis. a, A, or + transpose amongst the three axis. The screen 
maintains the level 1 info on the center system. 2 and 3 print the level 2
and level 3 information. Q quits the program.
	Really primitive.

TIMTBL xx yy zz time
	This prints a timetable for departing ships for a given system. The
time is measured in days and is an arbitrary number. The data is in the 
following format:
The Franhe (Arnelia) out of Sosen (9985 9981 10012)
	Departing 10 for Mouthit (9999 9998 10004)
	26 High berths 2 booked, 3 standby
	7 Low berths 2 booked

The _name_of_ship_ (_owning_corporation_) out of _origin_ (_coords_)
	Departing _day_ for _dest_ (_coords_)
	_total_ High berths _n_ booked [i.e. high passage], _n_ standby [i.e. 
middle passage]
	_n_ Low berths _n_ booked
The closer a ships gets to its departure date the fuller it will be. I used
it for a simple PBM game over the net that withered away.

SCAN xx yy zz
	This is really just a shell to search outward for whatever you want.
At the moment it prints where it is when a key is pressed and otherwise
searches for the mythical planet "Polo". Unless you are actually searching
for Polo you want to modify the program. It uses level 1 information but
that is easily changed (with the expense of speed). I have used it to look
for water worlds, high governments, etc... [see also capital].

NAME xx yy zz NumNames
	This uses the languages tables for the given system to produce
names. It produces as many names as given but the default is one.

HEXMAP xx yy zz time
	This is for producing a standard 15,000 mile per hex space map
for the area surrounding a planet. The time is optional to give settings
for the satelites. It doesn't seem to work for all planets correctly.
It first asks for the planet, then prints a list of the satelites and what
page they would appear on. It then asks for the number of pages wide and long.
It writes to the specified file in strips. Each is designed to fit on your
standard 8" paper in condenced mode. The strips can then be seperated and
taped together for your battle map.
	Try tracing the routes of the ships in coloured pencil as the
battle progresses. We did once and it was really worthwhile. Just like the
tatical maps in Star Wars!

PRMAP xx yy zz PlanetName
	This prints a triangle map of a planet surface. It prompts for a
file name to store the result in. It is straight ascii. It will ask for 
a triangle, specifier and size. See sysgen4 for an explanation of what 
these mean.

EPMAP xx yy zz PlanetName
	If under MS-DOS this prints a map to the PRN port. If under UNIX
you will want to change the line in the file or else a file called PRN will
be created. The graphics are printed with standard Epson FX-80 compatable
outputs. It will ask for a triangle, specifier and size. See sysgen4 for
an explanation of what these mean.

TCMAP xx yy zz PlanetName
	This is completely analagous to PRMAP except it prints the output
on the screen. It is only compilable under TurboC.

SECPRNT xx yy zz
	This prints a 10x10x10 "sector" starting with the coordinates given.
It uses Epson FX-80 compatable escape sequences for italics, and underligning
(to indicate POP of worlds). Waits for a keypress between pages.

CAPITAL xx yy zz
	This is similar to scan except it searches a 10x10x10 "sector" starting
with the coordinates given. It was originally used to determine the best planet
as a captial for a "sector". The current example searches for the highest tech
level. It uses level-1 information.

-------- TML Message #1782 --------

Archive-Message-Number: 1782
From: Adrian Hurt <adrian@cs.heriot-watt.ac.uk>
Subject: Re: Black Globes
Date: Thu, 15 Nov 90 10:05:58 GMT

"Brent L. Woods" <woodsb@zoo.ecn.purdue.edu> writes:
>      One small quibble.  "Prototype" isn't the best word to use.  I
> think that "copy" would be more accurate.  The device wasn't developed
> by Imperial (or any other contemporary) technology.  To quote from page
> 31 of _High Guard_:
> 
>           "Black globe generators are not available commercially; they
>      are recovered artifacts installed on a makeshift basis or
>      experimental versions installed on tech level 15 Imperial
>      warships."

" ... or experimental versions ..."
Sounds like prototypes to me.  Besides, in due time the Imperials should
learn how to copy the things.  And one or two places are now TL 16, and
should be capable of designing them.  The Darrians probably have a few
hidden away somewhere; and two Vargr worlds are TL 16, according to the
old Vargr Alien Module.

> 
>      Also, the behavior of the field is fairly well known--it won't
> explode or "move to a different universe."

This depends on how the PC's get hold of it.  (Assuming that they do, of
course - and assuming that they role-play properly, and don't make use of
what the players read in various manuals.)  If they got one by looting an
Imperial warship, they are probably more powerful than they have any right
to be, but can probably interrogate someone from the ship.  If they got one
the same way as the Navy did, by looting an Ancient base, and if the Navy
hasn't been publishing documents about black globes, then the PC's  will
not know what they have, or what it does.

>           "If a ship absorbs enough energy to make a jump, and is
>      supplied with sufficient fuel, it may jump at the end of the turn."
> 
>      Of course, this can be dangerous.  If you overload your capacitors,
> your ship is destroyed (by violently exploding capacitors, I guess).  I
> imagine that it's not a very good idea if you only have your jump drive
> capacitors available.

I don't see the danger.  If the ship has absorbed enough energy to make the
jump, it absorbed the energy into the jump capacitors.  If it still exists,
it hasn't overloaded the capacitors.  There should be no risk of overload
due to trying to jump - either the capacitors are sufficiently charged for
the jump, leave them alone; or they need a little more charge, give it to
them.

- - -- 
 "Keyboard?  How quaint!" - M. Scott

 Adrian Hurt			     |	JANET:  adrian@uk.ac.hw.cs
 UUCP: ..!ukc!cs.hw.ac.uk!adrian     |  ARPA:   adrian@cs.hw.ac.uk

-------- TML Message #1783 --------

Archive-Message-Number: 1783
Date: Thu, 15 Nov 90 11:09 EDT
From: METLAY@vms.cis.pitt.edu
Subject: The TDR Manifesto

I hereby designate the official name of the alternate-rules project to
be TDR, short for Traveller Done Right. I hereby declare myself in charge
of TDR, with final editorial rights over what is and isn't considered 
part of the approved package. I hereby declare that TDR will be public
domain and will be distributed via Email, and state my intention to 
prevent any and all attempts to inform either GDW or DGP of our work,
knowing full well that both companies will refuse to believe that a project
of this magnitude would be attempted without hope of monetary gain, hence
encouraging copyright infringement suits and the ruin of the careers of
several promising young RPG writers, myself included. I hereby order that
only vanilla ASCII be used for rules submissions, and that the Archivist 
reserve the right to keep or refuse any submission violating these rules.
I hereby declare computer software to be an unnecessary fringe project of
the TDR push, and leave it open for another user group to jabber about and
argue over until it dies of inertia-- TDR will consist of hard copy ONLY.
I hereby designate Mark Cook as the Archivist for all TDR materials, and
declare my intention to delete without forwarding any material on TDR sent
to me from here on. I hereby ask any and all individuals who refuse to 
abide by these rules to go stick their collective head in a pig. I hereby
request that any and all individuals who are serious enough about making 
these rules work and work well prove their intentions by submitting rules
packages to Mark at their earliest opportunity, and by calling me at
(412) 521-3548 evenings and weekends AFTER 12PM, effective Saturday, and
be willing to back up their wind with results.

We will worry about redistribution of material when and if we have anything
worth redistributing.  

metlay

[Whew! The original subject line was TDR: The Word From On High, but
metlay gave me permission to replace it with a stronger title that I
suggested -- James]

-------- TML Message #1784 --------

Archive-Message-Number: 1784
Date: Wed, 14 Nov 90 22:30:58 -0800
From: George William Herbert <gwh@ocf.berkeley.edu>
Subject: Copyrights & Such


Good point.  TDR is neutral enough that GDW won't have a copyright cow,
etc.  As for the predicted immenent demise of TDR: 8-P we shall survive 8-)

BTW: random vehicle design commentary; if you attempt to use a COACC engine
in another vehicle, be Very Very careful.  from analysis and comparason to
existing engines, they're twice as powerful (or more) than they should be.
My COACC rework is taking this into account, and making some other changes,
but you might want to think twice about the Fusion-Rocket powered starships.

- - -george william herbert
gwh@ocf.berkeley.edu   OCF Staff

-------- TML Message #1785 --------

Archive-Message-Number: 1785
Date: Wed, 14 Nov 90 22:21:20 -0800
From: George William Herbert <gwh@ocf.berkeley.edu>
Subject: The Drives Revision: my position summary...


	I've been having email conversations with Robert Dean about what to
do with maneuver drives.  I'm going to relist some of the salient points and
conclude by asking a question I asked Rob... whether strict reality or 
retaining compatability is more important.

[i'm trying to be neutral but probably failed... 8-]

	The first point is that it's obvious that the current description
and justification for maneuver drives won't cut it as is.  
	Second point is that it doesn't matter for most ships that players will
deal with, as a simple change to thrust-based will not change the maneuver 
drive mass-to-performance for most 'normal' ships.  Counterpoint: there are 
a lot of non-'normal' ships out there, and any such move would render the
designs incompatable.  Subpoint of this would be a 'flavor-of-game' alteration,
because heavily armoured naval ships would end up with 1-G or less and most
player ships will be able to RUN AWAY 8-) ...
	Third point: my pseudo-physics explanation for reactionless and 
volume-based drives seems to work, and it remains compatable. 
	Fourth point: so does Rob's thrust based... and it's easier for some
people to swallow.

[rob, fill in here if i missed anything important...]

Anyway: my conclusion is thus: we can make one of two changes; either go
with the easier-to believe thrust based drives, and render starships outside
the 'normal' range incompatable (and possibly less useful [personal comment])
or, we can accept the somewhat further-out volume based system and remain
compatable with previous design rules.
	I have a personal preference for which way to go, but since it's not
just my project, other people ought to have a say.  Let the debate begin 8-)

- - -george william herbert
gwh@ocf.berkeley.edu   OCF Staff

-------- TML Message #1786 --------

Archive-Message-Number: 1786
Date: Wed, 14 Nov 90 21:32:59 -0800
From: George William Herbert <gwh@ocf.berkeley.edu>
Subject: file formats...


Ascii.  It's the only one everyone understands.
We're going to be having enough problems with people not liking rules
mods than to add formatting to the fray. 8-)

- - -george
[we can always have someone mac the results to make them nice-like]

-------- End of TML Messages --------

